
Application No.: 09/289,513 Group Art Unit: 3626 

Filing Date: April 9,1999 Examiner: C. Gilligan 

For: SECURE ONLINE MUSIC DISTRIBUTION SYSTEM 



DATE OF DEPOSIT: September 15, 2003 

I HEREBY CERTIFY THAT THIS PAPER IS BEING 
DEPOSITED WITH THE UNITED STATES POSTAL 
SERVICE AS FIRST CLASS MAIL, POSTAGE PREPAID, 
ON THE DATE INDICATED ABOVE AND IS 
ADDRESSED TO THE COMMISSIONER FOR PATENTS, 
P.O. BOX 1450, ALEXANDRIA, VA 22313-1450. 



TYPE^N^ffcfE: Kenneth R. Eiferman 
REGISTRATION NO.: 51,647 

MS Appeal Brief - Patent 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 



APPEAL BRIEF TRANSMITTAL 
PURSUANT TO 37 CFR § 1,192 

Transmitted herewith in triplicate is the APPELLANTS' SUPPLEMENTAL BRIEF. 
PURSUANT TO 37 C.F.R. § 1.193(b)(2)(h), Applicants hereby request reinstatement of the 
. Appeal in this application with respect to the Notice of Appeal filed on November 15, 2002. 

| | Applicant(s) has previously claimed small entity status under 37 CFR § 1.27 . 

| | Applicant(s) by its/their undersigned attorney, claims small entity status under 37 
CFR§ 1.27 as: 

j | an Independent Inventor 

| | a Small Business Concern 

| | a Nonprofit Organization. 

□ Petition is hereby made under 37 CFR § 1.136(a) (fees: 37 CFR § 1.17(a)(l)-(4) to 
extend the time for response to the Office Action of to and through 

comprising an extension of the shortened statutory period of month(s). 
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The Commissioner is hereby requested to grant an extension of time for the 
appropriate length of time, should one be necessary, in connection with this filing or 
any future filing submitted to the U.S. Patent and Trademark Office in the above- 
identified application during the pendency of this application. The Commissioner is 
further authorized to charge any fees related to any such extension of time to Deposit 
Account 23-3050. This sheet is provided in duplicate. 

A check in the amount of $320,00 is attached. Please charge any deficiency or credit 
any overpayment to Deposit Account No. 23-3050. 
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appropriate length of time, should one be necessary, in connection with this filing or any 
future filing submitted to the U.S. Patent and Trademark Office in the above-identified 
application during the pendency of this application. The Commissioner is further authorized 
to charge any fees related to any such extension of time to deposit account 23-3050. This 
sheet is provided in duplicate. 
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responds to the outstanding rejections as presented in the Office Action mailed June 27, 
2003. 



09/18/2003 AH0NDAF1 00000020 09289513 

01 FC:1402 320.00 OP 



MSFT-1701/303314.1 



-2- 



PATENT 



A. REAL PARTY IN INTEREST 

The present application has been assigned to MICROSOFT 
CORPORATION. The inventors assigned their respective interests in the present 
application to LIQUID AUDIO, INC. by an assignment recorded April 9, 1999 at reel 
9892, frame 0951. Subsequently, LIQUID AUDIO, INC. assigned its interest in this 
application to MICROSOFT CORPORATION by an assignment dated September 27, 
2002. The September 27, 2002 assignment was forwarded to the Patent and Trademark 
Office for recordation on December 16, 2002; acknowledgment of this recordation has 
not yet been received. 

B. RELATED APPEALS AND INTERFERENCES 

There are no related appeals or interferences. 

C. STATUS OF CLAIMS 

1. Claims 1-49 are pending, of which claims 1 and 39 are independent. 
Claims 1-49 are reproduced in Appendix A, attached hereto. Claims 1-49 stand rejected. 
Claims 1-3, 10-26, and 39-49 have been rejected under 35 U.S.C. § 102(e), as being 
anticipated by U.S. Patent No. 5,715,314 to Payne, et al. (hereinafter "Payne"). Claims 4- 
9 have been rejected under 35 U.S.C. § 103(a) as being unpatentable over Payne in view 
of U.S. Patent No. 6,236,971 to Stefik, et al. (hereinafter "Stefik"). Claims 27-38 have 
been rejected under 35 U.S.C. § 103(a) as being unpatentable over. Payne. 

D. STATUS OF AMENDMENTS 

An after-final amendment to claim 6 was filed in response to the Final 
Rejection, and the Examiner indicated that this amendment would be entered for the 
purpose of this appeal. 



MSFT-1701/303314.1 



-3- 



PATENT 



In the Final Rejection dated July 19, 2002, claims 6-8 had been rejected 
under 35 U.S.C. § 1 12, second paragraph. In response to the Final Rejection, applicant 
filed an amendment under 37 C.F.R. § 1.116 amending claim 6. In a December 17, 2002 
Advisory Action, the Examiner found that the after-final amendment had overcome the 
35 U.S.C. § 1 12 rejection of claims 6-8, and agreed to enter the amendment for the 
purpose of this appeal. Thus, the amendment to claim 6 will be treated as having been 
entered, and the reproduction of the pending claims at Appendix A reflects this 
amendment. 

In the Rejection dated June 17, 2003, the Examiner reopened prosecution 
setting forth new grounds of rejection with respect to claims 6-8. In the Rejection, the 
Examiner stated, "It was not the Examiner's intent to indicate claims 6-8 as allowable in 
the Advisory Action mailed 12/17/02 in paper number 17. However, since the Advisory 
Action provided no explanation of how the amended claims would be rejected, the 
rejection is now provided herein." This Supplemental Brief thus includes the arguments 
presented with respect to claims 1-5 and 9-49 in the previously filed brief of March 14, 
2003. Furthermore, this Supplemental Brief states that claims 6-8 are patentable at least 
by reason of their dependency on independent claim 1 . 

E. SUMMARY OF THE INVENTION 

The present invention relates to the distribution of digital products, such as 
music, videos, etc., over wide-area networks. The invention makes use of various 
components that communicate with each other over a wide-area network, and that 
cooperate with each other to effectuate the distribution of digital products. 1 

In order to purchase and receive a digital product in accordance with the 
invention, a purchaser uses his/her computer (the "client computer") to contact a • 
"merchant computer." The merchant computer receives and processes requests to 



1 Application, p. 5. 
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purchase digital products. 2 After the purchaser has transmitted a payment authorization to 
the merchant computer, the merchant computer transmits a "content reservation request" 
to a content manager computer. 3 The content reservation request contains data that 
specifies which product the purchaser has purchased. 4 If the specified product is present 
in the content manager's database, then the content manager creates a "voucher packet." 
The voucher packet contains a "receipt token," which is later presented to a "delivery 
server" in order to allow delivery of the product to the purchaser. 5 

Thus, the user initially engages in a purchase transaction with the 
merchant computer; the merchant computer informs the content manager computer that 
the user has paid for a particular product; and the content manager creates a receipt token 
that ultimately directs a delivery server to provide the user with the product that the user 
has paid for. 

The independent claims of the present application (1 and 39) recite 
methods of conducting electronic commerce, including the above-described interaction 
between the merchant computer and the content manager. In particular, claim 1 recites 
that a "merchant computer system" receives a request to purchase a digital product and 
also receives payment data, and that a "content manager computer system" then receives 
a request from the merchant computer system that the purchased product be delivered to a 
client. Claim 39 recites that the merchant computer system receives a request to purchase 
a digital product (and also receives payment data), and that a request for a "reservation" 
of the product is sent to a content manager computer system. 

F. ISSUE ON APPEAL 

Whether claims 1-49 patentably define over Payne and/or over Payne in 

view of Stefik. 



2 Application, p. 6. 

3 Application, p. 32. 
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G. GROUPING OF CLAIMS 

For the purpose of this appeal, the following groups of claims stand or fall 

together: 

Group I: Claims 1-8, 10-12, 14-22, and 24-38; 

Group II: Claims 39-41 and 43-49; 

Group III: Claim 9 

Group IV: Claims 13 and 42 

Group V: Claim 23. 

H. ARGUMENT 

In the Office Action dated July 19, 2002, the Examiner finally rejected 
independent claims 1 and 39 as being anticipated by Payne under 35 U.S.C. §§ 102(e). 
Thus, appellants initially focus their argument on why claims 1 and 39 are not anticipated 
by Payne, and will then turn to a discussion of certain dependent claims. 

Independent claim 1 is not anticipated by Payne 

Independent claim 1 is directed to a "method for conducting electronic 

commerce through a computer network." In claim 1 , both a "merchant computer system" 

and a "content manager computer system" participate in the claimed method. In 

particular, claim 1 recites the following steps: 

receiving, in a merchant computer system . . . , a 
purchase request for a digital product; 

receiving payment data in the merchant computer 
system wherein the payment data specifies remuneration 
for the digital product; 



5 Application, p. 33. 





MSFT-1701/303314.1 



-6- 



PATENT 



receiving, in the content manager computer system, 
a delivery request signal from the merchant computer 
system wherein the delivery request signal requests 
delivery of the digital product to a client computer system 



In other words, claim 1 calls for a "merchant computer system" to do both of the 



following: 



• Receive a purchase request for a digital product; and 

• Send to the content manager computer system a request that the 
digital product be delivered to a client 



This structure is substantially different from Payne. While Payne uses separate computer 
systems to receive purchase requests (Payne's "payment computer") and to cause the 
purchased item to be delivered (Payne's "merchant computer") 6 , in Payne the "merchant 
computer" does not receive instructions from the "payment computer," but rather receives 
its instructions from the buyer, Payne is devoid of any teaching that a first computer 
system that receives a purchase request and payment, and a second computer system that 
requests delivery to the buyer, can communicate with each other directly. 



(such as "information products" or "hard goods") 7 by interacting with both a "payment 
computer" and a "merchant computer." The buyer transmits payment to the payment 
computer, 8 and then receives, from the payment computer, a Uniform Resource Locator 
(URL) representing the fact that the buyer has paid for an item. 9 Payne calls this URL the 
"access" URL. 10 This "access" URL is then instantiated as a link on the buyer's 
computer, and the buyer's computer follows the link by generating a Hypertext Transfer 



6 Unfortunately, the present application and Payne each use the term "merchant" in different ways, 
which may cause some confusion. In the present application, the "merchant computer system" receives 
payment for a digital product, while in Payne, the "merchant computer" fulfills the buyer's order after 
payment has been transmitted to the "payment computer." Thus, the "merchant computer system" of the 
present application receives the buyer's payment, whereas the "merchant computer" of Payne does not. 

7 Payne, col. 4, 11. 56-60. 

8 Payne, col. 5, 11. 27-47. 

9 Payne, col 7, 11. 18-30. 

10 Payne, col. 7, 11. 31-32 & FIG. 2G, element 90. 



Payne teaches that a buyer engages in a transaction to purchase a product 
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Protocol (HTTP) request based on the URL and transmitting this request to the merchant 
computer." The merchant computer then verifies the information contained in the request 
based on the URL, and uses this information either to provide a "fulfillment document" 
representing the buyer's purchase, or to provide the buyer with a document stating that 
access to the purchased product is not allowed. 12 

Thus, there is a crucial distinction between claini 1 and Payne: In claim 1, 
the request to deliver a product is sent from computer that receives payment (the 
"merchant computer system") to the computer that causes the purchase to be fulfilled (the 
"content manager computer system"). In Payne, no such direct communication takes 
place. 

The fact that claim 1 calls for the merchant computer system to 
communicate directly with the content manager is significant because it provides a 
measure of security that cannot be realized by the system of Payne: In Payne the buyer is 
responsible for transmitting to the merchant computer the very data (in the form of an 
HTTP request based on the "access" URL) that informs the merchant computer that the 
buyer has paid for a valuable product. The HTTP request contains information such as: 
which product the buyer is entitled to receive, how long the buyer is entitled to use the 
product for, and the network address identifier of the buyer's computer. 13 Since the buyer 
handles the URL on which the HTTP request is based, there is a possibility that the buyer 
will tamper with this data, thereby allowing the buyer to receive products he has not paid 
for, or that the buyer will extend the time that he is entitled to use the product, or that the 
buyer will attempt to grant access to the product to a different buyer who has not paid for 
the product. No such tampering is possible in the method of claim 1 , because the 
merchant computer sends the delivery request directly to the content manager computer, 



11 See Payne, FIG. 2H, element 92; col. 9, 11. 51-61. 

12 Payne, col. 7, 11. 36-54. 

13 Payne, col. 7, 11. 18-23. 
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without involving the buyer at all. 14 

In the Final Rejection, the Examiner has not cited any portion of Payne 
that teaches that a single system both: (1) receives a purchaser's payment for a product, 
and (2) sends a request to another system directing that the purchaser receive the product. 
Instead, the Examiner has cited two separate computers in Payne that allegedly perform 
the function of the claimed "merchant computer system." As described in appellants 5 
response to the final rejection, the Examiner has found that: 

• When the claimed "merchant computer system" is receiving a 
purchase request from the buyer, the merchant computer system is 
Payne's "payment computer"; and 

• When the claimed "merchant computer system" is sending a 
request to the content manager computer system, the merchant 
computer system is Payne's "buyer's computer." 15 

Thus, the Examiner combined two different computers in Payne to accomplish what a 
single computer does in claim 1 . As discussed above, the distinction of two computers 
versus one is significant and has implications for the security of the underlying system. 

When appellants, in the November 25, 2002 response to the Final 
Rejection, pointed out that the Examiner had combined two separate structures in Payne 
(the "payment computer" and the "buyer's computer") to do what claim 1 accomplishes 
with a single "merchant computer system,", the Examiner responded by stating that he 
was not actually reading any function of the claimed "merchant computer system" onto 
both Payne's "payment computer" and "buyer's computer." Rather, the Examiner asserts, 
the rejection reads the claimed "merchant computer system" onto only Payne's "payment 



14 It should be noted that, in the present invention, a digital product is delivered to the purchaser 
from a delivery server, and the user may handle the data that instructs the delivery server to deliver this 
product. However, even if the delivery server were analogous to Payne's merchant computer - and the 
Examiner has not asserted that any such analogy exists - the threshold issue on this appeal is whether the 
claimed "content manager computer system" reads on Payne's merchant computer (or any other structure 
described in Payne). As appellants have argued herein, the content manager computer system does not read 
on Payne's merchant computer system, because Payne's merchant computer system does not communicate 
directly with the payment computer that receive a purchase request and payment. 

15 See 1 1/25/02 Amendment, p. 4. 
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computer," and, while Payne appears to teach that a URL is sent from the buyer 's 

computer to the merchant computer, Payne is actually sending the URJL from the payment 

computer to the merchant computer via the buyer's computer. In the Examiner's words: 

Payne et al. teach a step of sending an access URL . . . from 
the payment computer 14 ... to the buyer computer 12 
which, in turn, sends it to the merchant computer 14 .... 
There are no steps recited in the claims that require the 
delivery request signal to be sent directly to the content 
manager computer from the merchant computer without 
passing through any intervening computers. 16 

Essentially, the Examiner characterizes Payne's buyer's computer as a mere conduit 

through which the payment computer sends a URL to the merchant computer. This 

characterization of Payne is wrong, and represents a misunderstanding of the process 

described in Payne. Payne's buyer's computer is not a mere conduit in the sending of data 

from one place to another; the buyer's computer participates in the creation of data, and 

sends to the merchant computer data that is different from that which it receives from the 

merchant computer. 

According to Payne, the concept of "sending" a URL means two different 

things depending upon whether the URL is specified as a "redirection." This fact is 

significant, because in Payne the "access" URL is sent from the payment computer to the 

buyer's computer as a redirection, but from the buyer's computer to the merchant 

computer as a non-redirection. Thus, Payne's buyer's computer does not merely pass 

along data between the payment computer and the merchant computer. Instead, the 

buyer's computer receives data (the access URL) from the payment computer, processes 

that data in some way, and then sends different data to the merchant computer. Since the 

merchant computer does not receive the same data that the payment computer sent to the 

buyer's computer, the Examiner's characterization of the buyer's computer as a mere 

"intervening" computer in the sending of data from one computer to another is simply 



16 See Advisory Action, p. 2. 
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wrong. 



Payne explains the "sending" of URLs as follows: 

Whenever the present application states that one 
computer sends a URL to another computer, it should be 
understood that in preferred embodiments the URL is sent 
in a standard HTTP request message, unless a URL 
message is specified as a redirection in the present 
application. . . . The term "URL" as used in the present 
application is an example of a "link," which is a pointer to 
another document or form . . . , 17 



In other words, "sending" a URL has a different meaning depending upon whether the 
sending is a redirection. The "access" URL is clearly a "redirection," since Payne states 
that the "payment computer sends redirect to access URL to buyer's computer." 18 Thus, 
when Payne's "access" URL is sent to from the payment computer to the buyer's 
computer, the URL becomes a link on the buyer's computer. When that link is followed, 
the buyer's computer generates an HTTP request message based on the URL, and it is 
this HTTP request message - not the original access URL - that is sent to the merchant 
computer. 



Thus, contrary to the Examiner's reasoning, Payne does not teach that the 



buyer's computer merely carries the "access" URL en route from the payment computer 
to the merchant computer. Instead, the buyer's computer receives one thing from the 
payment computer (a URL) and then sends another thing (an HTTP request message) to 
the merchant computer. The buyer's computer - by generating the HTTP request message 
based on the URL - is an active participant in the process described by Payne, not a mere 
"intervening computer." The Examiner's argument on claim 1 is wholly based on the idea 
that the buyer's computer is simply passing along something from the payment computer 
to the merchant computer. This reasoning is simply wrong. Since the Examiner's 
argument on claim 1 is based on a misapprehension as to what the buyer's computer in 



17 Payne, col. 9, 11. 51-61 (emphasis added). 

18 Payne, FIG. 2G (emphasis added); see also, col. 7, 1. 31. 
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Payne is sending to the merchant computer, the rejection of claim 1 as being anticipated 
by Payne cannot stand. 

Accordingly, appellants respectfully submit that claim 1 is patentable over 
Payne, and that dependent claims 2-38 are patentable at least by reason of their direct or 
indirect dependency on claim 1 . Thus, appellants request that the rejection of claims 1-38 
be reversed. (Claims 1-38 include all of the Group I claims, and also includes certain 
claims in Groups III, IV, and V. For reasons discussed below, there are additional reasons 
why the rejection of the Group III, IV, and V claims should be reversed.) 

Independent claim 39 is not anticipated by Payne 

Independent claim 39 is directed to a method for conducting electronic 

commerce through a computer network, and calls for: 

receiving, in a merchant computer system of the 
computer network, a purchase request for the digital 
product; 

receiving payment data in the merchant computer 
system wherein the payment data specifies remuneration 
for the digital product; 

sending a request for reservation of the digital 
product to a content manager computer system . . . which is 
coupled to the merchant computer system through the 
computer network; .... 

In other words, claim 39 calls for both a merchant computer system and a content 

manager computer system. A request to purchase a digital product, and payment for that 

product, are sent to the merchant computer system, and a request for "reservation" of the 

digital product is sent to a content manager computer system. Notably, the content 

manager computer system is coupled to the merchant computer system through a 

computer network. 

The Examiner rejected claim 39 as being anticipated by Payne. As with 
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claim 1, the Examiner reads the claimed "merchant computer system" onto Payne's 
"payment computer," and reads the claimed "content manager computer system" onto 
Payne's merchant computer. However, as discussed above, the relationship between 
Payne's payment computer and merchant computer on the one hand, and the relationship 
between the claimed merchant computer system and content manager computer system 
on the other hand, are different. 

At a minimum, Payne contains no teaching that the payment computer is 
connected through a network to the merchant computer. As discussed above, Payne's 
payment computer and merchant computer communicate by the payment computer 
sending a URL to the buyer's computer, which then generates an HTTP message based 
on the URL. There is no teaching in Payne that the payment and merchant computers 
communicate directly, or that they are otherwise connected to each other through a 
computer network. In fact, it is clear from the teachings of Payne - as described above in 
connection with claim 1 - that the payment computer and merchant computer 
communicate only indirectly through the buyer's computer, and require action by the 
buyer's computer in order to effectuate such communication. 

Since claim 39 requires that the merchant computer system and the content 
manager computer system be "coupled" to each other "through a computer network," it 
claim 39 recites at least one feature that is not taught by Payne. Thus, the rejection of 
claim 39 on the ground of anticipation must be reversed. Additionally, since claims 40-49 
are either directly or indirectly dependent on claim 39, the rejections of these claims must 

be reversed as well. 

Thus, appellants respectfully request that the rejection of claims 39-49 be 
reversed. (Claims 39-49 include all of the Group II claims, and also include one claim in 
IV; as discussed below, there are additional and cumulative reasons why the Group IV 
claim should be reversed.) 
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Claim 9 

Claim 9 is dependent on claim 1, and recites the steps of "encrypting the 

digital product with [a] new encryption key" and "discarding the new encryption key." 

The Examiner found that claim 9 was obvious over Payne in view of Stefik (see Final 

Rejection, f 42). However, neither Payne nor Stefik teaches the discarding of an 

encryption key. The Examiner merely makes general reference to the "encryption 

element" of Stefik, and does not explain how Stefik (or Payne) teaches the discarding of 

an encryption key. Appellants submit that there is no such teaching or suggestion in 

Stefik (or Payne). 

As noted above, claim 9 (the Group III claim) is patentable at least by 

reason of its dependency on claim 1 . However, the foregoing provides and independent 

and cumulative reason why claim 9 is patentable over Payne and Stefik. Thus, the section 

103(a) rejection of claim 9 should be reversed. 

Claims 13 and 42 

Claim 13 is dependent on claim 1. The Examiner found that claim 13 was 
anticipated by Payne (see Final Rejection, ^ 13). Claim 13 recites that the merchant 
computer system sends data to a "payment authority" and receives payment authorization 
information from the "payment authority." The Examiner reads these features onto col. 1, 
11. 55-64 of Payne. The cited portion of Payne contains no such teaching. 

As described above, the participants in the Payne system are the payment 
computer, the merchant computer, and the buyer's computer. It is not clear how the 
Examiner derives this additional party - a "payment authority" ^ from the cited portion of 
Payne, or from any other portion of Payne. Appellants respectfully submit that Payne 
contains no such teaching. 

As noted above, claim 13 is patentable at least by reason of its dependency 
on claim 1 . However, the foregoing provides and independent and cumulative reason why 
claim 13 is patentable over Payne. Additionally, claim 42 is indirectly dependent on 
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1. Claim 22 recites, inter alia, that the "merchant computer system ... communicates the 
delivery request signal to the content manager computer system." As discussed above in 
connection with claim 1, the Examiner has analogized Payne's "payment computer" and 
"merchant computer" to the claimed "merchant computer system" and "content manager 
computer system," respectively. As further discussed in connection with claim 1 , Payne 
does not teach that the payment computer communicates with the merchant computer. 
Thus, the Examiner's finding that Payne anticipates claim 23 is incorrect. 



As noted above, claim 23 is patentable at least by reason of its (indirect) 



dependency on claim 1 . However, the foregoing provides and independent and 
cumulative reason why claim 23 is patentable over Payne. Thus, the section 102(e) 
rejection of claim 23 (the Group V claim) should be reversed. 

Conclusion 

For all the foregoing reasons, appellants respectfully request that the 
Board reverse the rejection of claims 1-49, and that this application be returned to the 
Examiner for allowance. 



Date: September 15, 2003 

WOODCOCK WASHBURN LLP 
One Liberty Place - 46 th Floor 
Philadelphia, PA 19103 
Tel: (215) 568-3100 
Fax: (215) 568-3439 




Kenneth R. Eiferman 
Registration No. 51,647 
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APPENDIX A 
Claims on Appeal 

1 . A method for conducting electronic commerce through a computer 
network, the method comprising: 

receiving, in a merchant computer system of the computer 
network, a purchase request for a digital product; 

receiving payment data in the merchant computer system wherein 
the payment data specifies remuneration for the digital product; 

sending a request for reservation of the digital product to a content 
manager computer system which can be different from the merchant computer system 
and which is coupled to the merchant computer system through the computer network; 

receiving, in the content manager computer system, a delivery 
request signal from the merchant computer system wherein the delivery request signal 
requests delivery of the digital product to a client computer system through the computer 
network; 

sending transaction identification data to the client computer 
system wherein the transaction identification data identifies the digital product and 
represents remuneration in accordance with the payment data; 

receiving, in a delivery computer system of the computer network, 
the transaction identification data from the client computer system; 

determining within the delivery computer system, in accordance 
with the transaction identification data, the digital product; and 

sending, from the delivery computer system, the digital product to 
the client computer system. 

2. The method of Claim 1 further comprising: 

sending, from the delivery computer system to the content manager 
computer system, a signal indicating that sending the digital product to the client 
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computer system is completed. 

3. The method of Claim 2 further comprising: 

recording, by the content manager computer system, purchase data 
identifying the digital product and indicating that the digital product was purchased. 

4. The method of Claim 3 further comprising: 

sending, by the content manager computer system, the purchase 
data to a media licensing computer system such that the media licensing computer system 
can apportion compensation for sales of the digital product. 



system and other purchase data from one or more other content manager computer 
systems to form aggregated purchase data; and 



system such that the rights agent computer system can apportion compensation for sales 
of the digital product. 

6. The method of Claim 5 wherein recording the purchase data comprises: 

encrypting the purchase data in such a manner that data held secret 
by the media licensing computer system is required for decrypting the purchase data. 

7. The method of Claim 6 wherein encrypting the purchase data is 
performed in such a manner that modification of the purchase data subsequent to the 
encrypting can be detected. 



5. The method of Claim 4 further comprising: 

aggregating purchase data from the content manager computer 



sending the aggregated purchase data to a rights agent computer 



8. The method of Claim 6 wherein encrypting the purchase data is 
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performed in such a manner that removal of the purchase data from a sequence of 
purchase data records subsequent to the encrypting can be detected. 

9. The method of Claim 1 wherein sending the digital product from the 
delivery computer system to the client computer system comprises: 

creating a new encrypting key which is intended to be used only 

once; 

encrypting the digital product with the new encryption key to form 
an encrypted digital product; 

sending the encrypted digital product to the client computer 

system; 

decrypting the encrypted digital product within the client computer 
system to recover the digital product; and 

discarding the new encryption key. 

10. The method of Claim 1 wherein requesting reservation by the 
merchant computer system comprises: 

encrypting data representing a requested reservation; 

sending the data as encrypted to the content manager computer 

system; and 

decrypting the data within the content manager computer system. 

1 1 . The method of Claim 1 wherein, in response to requesting reservation 
by the merchant computer system, the content manager computer system effects such a 
reservation of the digital product by: 

forming transaction data which include (i) the transaction 
identification data, (ii) product identification data which identifies the digital product, and 
(iii) binding data which binds the transaction to the client computer system; and 
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sending the transaction data to the merchant computer system. 



12. The method of Claim 1 1 wherein sending the transaction identification 
data comprises encrypting the transaction identification data. 

13. The method of Claim 1 further comprising: 

sending, from the merchant computer system, the payment data to 
a payment authority; and 

receiving, in the merchant computer system from the payment 
authority, payment authorization data. 

14. The method of Claim 13 further comprising: 

sending the payment authorization data to the content manager 

computer system. 



16. The method of Claim 14 further comprising: 

recording, by the content manager computer system, that payment 
for the digital product has been authorized. 

17. The method of Claim 16 further comprising: 

receiving, in the merchant computer system from the content 
manager computer system, acknowledgment data which indicates that payment for the 
digital product has been recorded. 



15. The method of Claim 14 wherein sending the payment authorization 



data comprises: 



encrypting the payment authorization data. 
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18. The method of Claim 17 wherein the acknowledgment data includes 
the transaction identification data and a payment authorization token which identifies 
payment authorization as recorded by the content manager computer system. 

19. The method of Claim 18 wherein the delivery request signal includes 
the transaction identification data and the delivery authorization token. 

20. The method of Claim 19 wherein the delivery request signal is 
generated in response to selection of a URL by the user wherein the URL specifies the 
transaction identification data and the delivery authorization token. 

21. The method of Claim 17 wherein the acknowledgment data is 

encrypted. 

22. The method of Claim 1 wherein the delivery request signal is received 
in the content manager computer system from the client computer system; and 

further wherein the delivery request signal is generated by the 
client computer system in response to user-generated control signals. 

23. The method of Claim 22 wherein the user-generated control signals are 
incident to a graphical user interface of a web browser; and 

further wherein the user-generated control signals cause the client 
computer system to send the delivery request signal to the merchant computer system 
which in turn communicates the delivery request signal to the content manager computer 
system. 

24. The method of Claim 1 wherein the delivery request signal includes 
the transaction identification data. 
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25. The method of Claim 24 wherein the delivery request signal is 
generated in response to selection of a URL by the user wherein the URL specifies the 
transaction identification data. 

26. The method of Claim 1 wherein the transaction identification data, as 
received by the delivery computer system is certified as originating from the client 
computer system. 

27. The method of Claim 26 wherein the transaction identification data is 
certified by signing of the transaction identification data using asymmetric-key 
encryption. 



28. The method of Claim 1 wherein the digital product includes a digitized 

audio signal. 

29. The method of Claim 28 wherein the digital product includes a 
selection of one or more musical pieces. 

30. The method of Claim 29 wherein the digital product further includes 
textual data representing lyrics of the one or more musical pieces. 

3 1 . The method of Claim 29 wherein the digital product further include 
textual data representing liner notes of the one or more musical pieces. 



32. The method of Claim 29 wherein the digital product further include 
textual data representing artist credits of the one or more musical pieces. 
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33. The method of Claim 29 wherein the digital product further include 
textual data representing critical commentary of the one or more musical pieces. 

34. The method of Claim 29 wherein the digital product further includes 
one or more graphical images of album artwork to accompany the one or more musical 
pieces. 

35. The method of Claim 29 wherein the digital product further includes 
one or more graphical images of advertisement artwork to accompany the one or more 
musical pieces. 

36. The method of Claim 35 wherein the advertisement artwork is selected 
specifically for the client computer system. 

37. The method of Claim 36 wherein the advertisement artwork is selected 
specifically for the client computer system in accordance with information of the user of 
the client computer system. 

38. The method of Claim 37 wherein the information of the user is 

demographic. 

39. A method for conducting electronic commerce through a computer 
network, the method comprising: 

receiving, in a merchant computer system of the computer 
network, a purchase request for a digital product; 

receiving payment data in the merchant computer system wherein 
the payment data specifies remuneration for the digital product; 
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sending a request for reservation of the digital product to a content 
manager computer system which can be different from the merchant computer system 
and which is coupled to the merchant computer system through the computer network; 

receiving, from the content manager computer system, voucher 
data which is readable by the content manager computer system and which represents to 
the content manager computer system a transaction in which the remuneration specified 
by the payment data is exchanged for the digital product. 

40. The method of Claim 39 further comprising: 

receiving, from the content manager computer system, inventory 
data which specifies available digital products, including the digital product, and 
specified remuneration to the content manager computer system for each of the available 
digital products. 

41. The method of Claim 40 wherein requesting reservation comprises: 

encrypting data representing a requested reservation; 

sending the data as encrypted to the content manager computer 

system; and 

decrypting the data within the content manager computer system. 

42. The method of Claim 40 further comprising: - 

sending, from the merchant computer system, the payment data to 
a payment authority; and 

receiving, in the merchant computer system from the payment 
authority, payment authorization data. 

43. The method of Claim 42 further comprising: 

sending the payment authorization data to the content manager 
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computer system. 



44. The method of Claim 43 wherein sending the payment authorization 



data comprises: 



encrypting the payment authorization data. 



45. The method of Claim 44 further comprising: 

receiving, in the merchant computer system from the content 
manager computer system, acknowledgment data which indicates that payment for the 
digital product has been recorded. 

46. The method of Claim 45 wherein the acknowledgment data includes 
the transaction identification data and a payment authorization token which identifies 
payment authorization as recorded by the content manager computer system. 

47. The method of Claim 46 wherein the delivery request signal includes 
the transaction identification data and the payment authorization token. 

48. The method of Claim 47 wherein the delivery request signal is 
generated in response to selection of a URL by the user wherein the URL specifies the 
transaction identification data and the payment authorization token. 

49. The method of Claim 45 wherein the acknowledgment data is 

encrypted. 



